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RESUMING COMMUNICATION OF CONTENT DATA ON THE INITIAL CHANNEL WHEN THE INITIAL 
AND THE NEW ACCESS POINT PERFORM HANDOVER STEPS 



Field of the Invention 



10 



The present invention relates to wireless access networks, whi ch include 
wireless local area networks (WLANs) and wireless wide area networks 
(WWANs), and relates in particular to handovers in wireless access networks. 
The present invention relates in particular, but not exclusively, to handover of a 
mobile node (MN) between two access points (APs) under the Inter i Access Point 
Protocol (IAPP) in a WLAN operating according to the IEEE 802.11 standard. 



Background of the Invention 



Local area networks (LANs) are computer and communications networks 
15 which users may access at different access points (APs). One type of LAN is a 
wireless local area network (WLAN) in which user's equipment may be mobile 
and connects with an access point by means of a wireless link. A wel| known 
operating standard for WLANs is IEEE 802.11. 



20 Mobile user equipment in a WLAN is usually referred to as a [nobile node 

(MN). Some examples of an MN are a mobile telephone with a WLA M interface, 
a laptop computer with a WLAN interface, and a personal data assistant (PDA) 
with a WLAN interface. 
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When a MN moves, a requirement can arise for the MN to be landed over 
from one AP (which may be called the "initial" or "old" AP) to a "new" AP. 
Handover is controlled by a handover protocol. In the case of a WLAN operating 
according to IEEE 802.11, the handover protocol is typically the Intel Access 
5 Point Protocol (IAPP), which applies across the "initial" and the "new" AP. 

The IAPP provides a means for transferring so-called "contexi " from the 
old AP to the new AP. The term context is used to describe information relating 
to the MN and its operation that is required at an AP for the AP to p] ovide 

10 service to the MN. Such information may include security informatic >n such as 
authentication information, quality of service (QoS) information, anc so on. 
However, in typical WLANs, and operating standards thereof, handover causes a 
break in service before the new AP takes over serving the MN. This may be 
disadvantageous, particularly when the MN is running a real-time a ^plication, 

15 e.g. a real-time multi-media application such as receiving and displaying real- 
time video. 



20 



In some WLANs, and operating standards thereof, so-called 
processes (in which two or more APs effectively serve the MN at the 
have been applied in an attempt to alleviate the disadvantages of a 
service due to handover. 



spft handover 

same time) 
bteakin 



However, in many WLANs, or operating standards thereof, soft handover 
is not possible and/or not desirable. This is the case for WLANs operating under 
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the IEEE 802.11 standard, in which adjacent APs typically operate 
frequency bands. 



in|different 



J 



Also, a problem related to QoS provision may arise with hand over of real- 
5 time applications in WLANs. In particular, where details of operatin ; standards 
are based upon standards designed originally for fixed networks, a p rocess of 
requesting and obtaining a required QoS level, using so-called resen ation paths, 
tends to be problematic in WLANs where a user is allowed to change access 
points, essentially due to the need for re-establishing reservation pat is after 

10 handover. For example, an Integrated Services (IntServ) framework, as 

standardized by the Internet Engineering Task Force (IETF) and disc assed in R. 
Braden et al., 'Integrated Services in the Internet Architecture: an 0\ erview," 
RFC 1633, June 1994, provides a means for requesting and obtaining QoS per 
flow. IntServ uses Resource Reservation Protocol (RSVP), as described in R. 

15 Braden et aL, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 

Specif ication," RFC2205, September 1997, for implementing signalling associated 
with this. However, having been designed originally for fixed networks, RSVP is 
an example of a process which tends to be problematic in WLANs. In particular, 
depending on the distance between the peers, considerable delays can arise, 

20 deteriorating the network performance during handovers, especially for real- 
time applications. 



25 



Considerations such as those discussed above with respect to WLANs also 
apply to wireless wide area networks (WWANs). WLANs and WWANs may be 
considered to be two types of wireless access networks, and in this si )ecification 
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the term "wireless access network" is to be understood to include at 
WLANs and WWANs, as well as any other access networks whose 
characteristics are able to benefit from the following invention. 



east 



Summary of the Invention 



10 
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In a first aspect, the present invention provides a method of changing 
access points for a mobile node, or performing handover, in a wirekss access 
network, for example a wireless local area network or a wireless wide area 
network, the method comprising: the mobile node communicating content data 
on an initial channel via an initial access point of the wireless access network; the 
mobile node sending a handover request on a new channel to a new access point 
of the wireless access network; the mobile node resuming communication of 
content data on the initial channel via the initial access point; elements of the 
wireless access network, including the initial access point and the new access 
point, performing handover steps while the mobile node performs the resumed 
communication of content data on the initial channel via the initial access point; 
and when the handover steps are completed, the mobile node communicating 
content data on the new channel via the new access point. 

The step of the mobile node performing the resumed communication of 
content data on the initial channel via the initial access point may end by virtue 
of the mobile node switching from the initial channel to the new chainel in 
response to an instruction message from the wireless access network which is 
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sent as part of the handover steps performed by elements of the wire 
network. 



ess access 



The method may further comprise the wireless access networl; sending a 
completion message to the mobile node informing the mobile node that the 
handover steps are completed. 



The step of the mobile node communicating content data on 
channel via the new access point may start in response to the mobile 
receiving the completion message. 



the 



new 
node 



The step of the mobile node switching from the initial channel) to the new 
channel in response to a message from the wireless access network wfhich is sent 
as part of the handover steps performed by elements of the wireless jccess 
network may be performed a predetermined or a calculated amount bf time after 
the mobile node receives the instruction message. 

The method may further comprise the step of the mobile node 
determining whether an expected data flow of the new access point is acceptable, 
for example in terms of quality of service. 

In a further aspect, the present invention provides a storage medium 
storing processor-implementable instructions for controlling a proces sor to carry 
out the method steps of any of the above aspects performed by the m obile node. 
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In a further aspect, the present invention provides a storage njedium 
storing processor-implementable instructions for controlling a procej sor to carry 
out the method steps of any of the above aspects performed by the a< cess points. 

5 In a further aspect, the present invention provides a mobile ncjde adapted 

to perform the method steps of any of the above aspects performed tjy the mobile 
node. 

In a further aspect, the present invention provides an access ppint adapted 
10 to perform the method steps of any of the above aspects performed by the access 
points. 

In a further aspect, the present invention provides apparatus lor changing 
access points for a mobile node, or performing handover, in a wireless access 

15 network, for example a wireless local area network or a wireless wid* area 

network, comprising: means for the mobile node to communicate content data on 
an initial channel via an initial access point of the wireless access network; means 
for the mobile node to send a handover request on a new channel to a new access 
point of the wireless access network; means for the mobile node to resume 

20 communication of content data on the initial channel via the initial access point; 
means for elements of the wireless access network, including the initj al access 
point and the new access point, to perform handover steps while thei mobile node 
performs the resumed communication of content data on the initial cthannel via 
the initial access point; and means for, when the handover steps are completed, 
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the mobile node to communicate content data on the new channel vijjt the new 
access point. 



The means for the mobile node to perform the resumed 
content data on the initial channel via the initial access point may be 
end the resumed communication by virtue of the mobile node swi 
initial channel to the new channel in response to an instruction 
wireless access network which is sent as part of the handover steps 
elements of the wireless access network. 



comn]junication of 
arranged to 
from the 
from the 
performed by 



td)ing j 



message 



The apparatus may further comprise means for the wireless access 
network to send a completion message to the mobile node informing the mobile 
node that the handover steps are completed. 



on 



The means for the mobile node to communicate content data 
channel via the new access point may be arranged to start communication 
content data in response to the mobile node receiving the completion 



The means for the mobile node to switch from the initial channel to the 
20 new channel in response to a message from the wireless access network which is 
sent as part of the handover steps performed by elements of the wireless access 
network may be arranged such that the switching is performed a predetermined 
or a calculated amount of time after the mobile node receives the instruction 
message. 

25 
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The apparatus may further comprise means for the mobile nofle to 
determine whether an expected data flow of the new access point is 



i cceptable. 



In any of the above aspects, the wireless access network may 
5 local area network operating according to the operating standard 



le 



IE1 E 



The present invention tends to alleviate or resolve problems a isociated 



with a break occurring between service from an old AP and a new A : 



a wireless 
802.11. 



\ by the 



MN sending a request to a new AP but then reverting to the old AP \ intil 
handover preparation in a fixed part of the WLAN is complete, or at least 
substantially complete, and the MN is informed of this. This tends to reduce 
handover latency between the old AP and the new AP and avoids breaks in 
service, thus improving in particular provision of real-time applicati >ns such as 
real-time multi-media applications. 

Brief Description of the Drawings 

Embodiments of the present invention will now be described, by way of 
example only, with reference to the accompanying drawings, in whi|h 

FIG. 1 is a schematic illustration of a wireless local area network (WLAN); 



FIG. 2 is a call sequence flowchart showing process steps emp 
prior art handover process; and 



oyed in a 
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FIG. 3 is a call sequence flowchart showing process steps emp|oyed in a 
handover process according to an embodiment of the invention. 

Description of Preferred Embodiments 

FIG. 1 is a schematic illustration of a wireless local area netwo :k (WLAN) 
1. The WLAN 1 comprises a transport network, which in this examp: e is an IP 
network 2, coupled to an authentication unit 3 and a plurality of accc ss points 
(AP's). The access points are coupled, via radio links, to various mob Lie nodes 
(MN's). In practise the WLAN 1 will typically comprise a large num ?er of AP's 
and MN's, but for clarity only two AP's, namely a first AP 4 and a se :ond AP 5 
are shown, and only one MN, namely a MN 6, are shown. When the MN 6 is 
coupled to the first AP 4 this is by a radio link 24; when the MN 6 is < oupled to 
the second AP 5 this is by a radio link 25. In this example the MN 6 h a laptop 
computer with a WLAN interface, but in general may be any known type, for 
example a mobile telephone with a WLAN interface or a personal di Lta assistant 
(PDA) with a WLAN interface. 

In this embodiment the WLAN 1 operates according to the w<P known 
operating standard IEEE 802.11. The authentication unit 3 is a Remote 
Authentication Dial-In User Service (RADIUS) server. 



25 



The WLAN 1 allows the MN 6 to communicate with an entity 
network 2. Such entity may be another user node of the WLAN cou 
network 2 via an AP. Another possibility is that the IP network 2 may 



via the IP 
to the IP 
be coupled 
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to a gateway to a public switched telephone network (PSTN), and thf entity is 
connected via the PSTN. The type and connection route of the entity! is 
unimportant to understanding this embodiment, and therefore in FI<fc. 1 and the 
following description this connection is presented in general terms aft a data 
5 route 8 coupled to the IP network 2. 

In operation, the MN 6 interacts with the IP network 2 via an |ccess point. 
More particularly, let us consider a scenario where the MN 6 is enga ;ed in a data 
session, and access is initially provided via, say, AP 4, which will the refore be 

10 termed hereinafter the initial AP 4. The data required to pass betwee i various 
elements may be divided into data representing the information con ent of the 
data session (hereinafter referred to as content data), and signalling < lata used to 
set up and maintain the flow of the content data between elements. < lontent data 
passes between the MN 6 and the initial AP 4, between the initial AI 4 and the IP 

15 network 2, and between the IP network 2 and the data route 8. Hand over specific 
signalling data, including encryption data, passes between the MN 6 and the 
initial AP 4, between the initial AP 4 and the IP network 2, and betw ten the IP 
network 2 and the authentication unit 3. 

20 Let us now consider when it is required or desired for the MI^ 6's access to 

the communications network 2 to be changed so that it then become ; provided 
by a different AP, e.g. the AP 5, which will therefore be termed herei nafter the 
new AP 5. The implementation of this is called handover. Conventic nally, this is 
performed using a handover mechanism, comprising for example th ? Inter 

25 Access Point Protocol (IAPP) and the IEEE 802.11 standard. 
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In this embodiment, the AP's 4, 5 and the MN 6 have been adi pted, to 
offer, and provide for, an adapted form of access handover, as will b : described 
in more detail below. 



The adaptation may be implemented in the respective elemen 



s in any- 



suitable manner. For example, new apparatus may be added to conv jntional 
AP's and MN's, or alternatively existing parts of a conventional AP'j and MN's 
may be adapted, for example by reprogramming of a one or more pi lessors 
therein. As such the required adaptation may be implemented in the form of 
processor-implementable instructions stored on a storage medium, s nch as a 
floppy disk, hard disk, PROM, RAM or any combination of these or >ther storage 
media. 



The adapted form of handover of this embodiment may be m&st readily 
understood by comparison with the conventional handover process, which is 
therefore described first, as follows. 



FIG. 2 is a call sequence flowchart showing process steps em 
prior art handover process. In the case of the MN 6, two separate 
are shown, an initial channel 14 which is the channel used by the 
communicate with the initial AP 4, and a new channel 15 which is 
used by the MN 6 to communicate with the new AP 5. The channels 
radio frequencies from each other, as specified in IEEE Std. 802.11 
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Initially, a data session is underway, via initial AP 4. This is represented in 
FIG. 2 by step 2 in which content data is passed between the MN6 oj erating on 
the initial channel 14, the initial AP 4, the IP network 2 and the data oute 8. In 
more detail, step 2 comprises: a step 2a in which content data is pass % A between 
the MN 6 operating on its initial channel 14 and the initial AP 4; a stc p 2b in 
which content data is passed between the initial AP 4 and the IP neb fork 2; and a 
step 2c in which content data is passed between the IP network 2 an< the data 
route 8. Although presented as a discrete step 2 for consistency in FI j. 2, it will 
be understood that this represents an ongoing two-way data flow pi x:ess. This 
data flow process is shown in FIG. 2 as being undertaken during a fi st time 
period 21. The active channel of the MN 6 during the first time perio I 21 is the 
initial channel 14. 



wi 1 



Then handover is performed by virtue of steps s4 to si 8 as 
described below. Steps s4 to sl8 are implemented over the course of 
time period 22, as shown in FIG. 2. The active channel of the MN 6 
second time period 22 is the new channel 15. Thus, during the secon|l 
period 22 the flow of content data is interrupted (i.e. step 2 does not 
during the second time period), since the MN 6 has switched to its n 
15, which corresponds to the new AP 5 rather than the initial AP 4, 
is not yet able to send content data to or receive content data from 



25 



Steps s4 to sl8 follow the protocol specified in the IEEE Std 
Inter Access Point Protocol (LAPP), which is a recommended practio 
standardized by the IEEE Working Group 802.1 If, and is specified ii 
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802.1 If/Draft 5, "Draft Recommended Practice for Multi-Vendor Acc »ss Point 
Interoperability via an Inter- Access Point Protocol Across Distribute n Systems 
Supporting IEEE 802.11 Operation". The IAPP provides capabilities or 
transferring context from one AP to another, through the fixed distri mtion 
system, in order to facilitate handovers across multi-vendor APs. (Tl e term 
context is used to describe information relating to the MN and its op iration that 
is required at an AP for the AP to provide service to the MN.) The I,/ 5 PP describes 
a service access point (SAP), service primitives, a set of functions an< . a protocol 
that will allow conformant APs to interoperate on a common distrib ition system, 
using the Transmission Control Protocol over IP (TCP/IP, where IP i > Internet 
Protocol) to exchange IAPP packets. Both IP in general, and more pa rticularly 
TCP/IP are well known to the person skilled in the art, hence will on y be briefly 
summarised here to the extent that, broadly speaking, they are protc cols that 
define procedures for exchange of packetized information, and are s verified in 
terms of different hierarchical layers, e.g. Layer-2, layer 3, according to different 
types of entities or functions needing to be consistent with each othe r. 



] :s: 



Referring to FIG. 2, at step s4, the message exchange during 
initiated by the MN 6 sending a Reassociate-Request message from 
channel 15 to the new AP 5. The Reassociate-Request message carrie^ 
Service Set Identifier (BSSID) of the initial AP 4. 



25 



The new AP 5 will need to communicate with the initial AP 4| 
do this, the new AP 5 will need the IP address of the initial AP 4. In 
mapping between BSSIDs and IP addresses can be either stored at 
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themselves, or at an authentication unit such as authentication unit 4 In this 
example, the mapping is held at the authentication unit. Therefore, a| step s6, the 
new AP 5 sends an Access-Request message to the authentication un 1 3, this 
message including the information of the BSSID of the initial AP 4. 

The authentication unit 3 processes this request, including loc king up the 
IP address of the initial AP 4 that it has mapped for the BSSID of the initial AP 4. 
At step s8, the authentication unit sends an Access- Accept message t :> the new 
AP 5. The Access- Accept message includes the IP address of the initi &1 AP 4, 

One option is for the communication between the AP's to be i ncrypted or 
otherwise made secure. This is the case in this example. Hence, the / ccess- 
Accept message sent, at step s8, from the authentication unit to the r ew AP 5 also 
includes a Security Key to enable the new AP 5 to prepare a security (block for 
sending to the initial AP 4. 



senc s 



Then security blocks are exchanged between the new AP 5 a: 
AP 4. This is implemented as follows. At step slO, the new AP 5 
Block to the initial AP 4. At step si 2, the initial AP 4 sends a Security 
Acknowledgment to the new AP 5. 



At step sl4, the new AP 5 sends a Move-notify message to the initial AP 4. 
This Move-notify message in effect informs the initial AP 4 that the 1 (DM 6 has 
requested to handover to the new AP 5. 



n J 



the initial 
a Security 
Block 



25 



WO 2005/060165 



PCT/EP2004/051740 



15 



20 



15 



At step si 6, the initial AP 4 sends a Move-response message t< > the new 
AP 5. This Move-response message and the Move-notify message ea li include a 
Context Block. Both the Move-notify message sent at step sl4 and th : Move- 
response message sent at step si 6 are IP packets carried in a TCP ses don 
5 between the two APs. These messages may contain authentication ir formation 
that allows the new AP 5 to accept the MN 6 without re-authenticati >n. 
However, the Context Block has a flexible structure which is able to : upport a 
range of information exchange. More specifically, it can consist of a i ariable 
number of Information Elements (IEs) of the form (Element ID, Leng th, 
10 Information). In this way, every IE can contain variable length inforr \ation, 
whose type is specified by the Element ID. Processing of the informs don 
transferred inside the IEs is beyond the scope of the IAPP, as it depe ids on the 
functionality of the APs, and will be arranged according to the requi rements or 
circumstances of a particular system or set up, as specified by the sk lied person. 



25 



At step sl8, the new AP 5 sends a Layer-2 (L2) Update Frameito the IP 
network 2. In response to this, the IP network 2 changes the data pat i to being 
switched via the new AP 5 instead of the initial AP 4. This is represe ited in FIG. 
2 by a step s20 in which the content data is passed between the MN6| operating 
on the new channel 15, the new AP 5, the IP network 2 and the data route 8. In 
more detail, step s20 comprises: a step s20a in which content data is massed 
between the MN 6 operating on its new channel 15 and the new AP >; a step s20b 
in which content data is passed between the new AP 5 and the IP ne work 2; and 
a step s20c in which content data is passed between the IP network Z and the 
data route 8. Although presented as a discrete step s20 for consistent y in FIG. 2, 
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it will be understood that this represents an ongoing two-way data fjpw process 
during a third time period 23, as shown in FIG. 20. 

The adapted form of handover of this embodiment will now I e described 
5 with reference to FIG. 3. 

FIG. 3 is a call sequence flowchart showing process steps emp oyed in the 
handover process of this embodiment. The same reference numerals as were 
used with respect to FIG. 2 are used again in FIG. 3 to indicate the two separate 
10 radio channels, i.e. the initial channel 14 and the new channel 15 used by the MN 
6. These channels are as described above with reference to FIG. 2. 

In the process of this embodiment, each of the prior art steps < escribed 
above with reference to FIG. 2 is carried out, but additional steps are now 

15 included. For the sake of completeness, the steps common to the pri< r art 

approach are renumbered and described again in the following desc iption of 
this embodiment made with reference to FIG. 3. Individually, these 5 teps 
corresponding to those present in the above described prior art proc tss again 
follow the IEEE 802.11 standard and the protocol specified in the Int :r Access 

20 Point Protocol (IAPP), which is a recommended practice currently st mdardized 
by the IEEE Working Group 802.11f, and is specified in IEEE Std. 80: .llf/Draft 5, 
"Draft Recommended Practice for Multi- Vendor Access Point Intero >erability via 
an Inter- Access Point Protocol Across Distribution Systems Support ig IEEE 
802.11 Operation 7 '. 
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Initially, a data session is underway, via initial AP 4. This is n presented in 
FIG. 3 by step s30 in which content data is passed between the MN6 operating on 
the initial channel 14, the initial AP 4, the IP network 2 and the data oute 8. In 
more detail, step s30 comprises: a step s30a in which content data is >assed 

5 between the MN 6 operating on its initial channel 14 and the initial J P 4; a step 
s30b in which content data is passed between the initial AP 4 and th IP network 
2; and a step s30c in which content data is passed between the IP net work 2 and 
the data route 8. Although presented as a discrete step s30 for consistency in FIG. 
3, it will be understood that this represents an ongoing two-way dat i flow 

10 process. This data flow process is shown in FIG. 3 as being undertak in during a 
first time period 31. The active channel of the MN 6 during the first i jime period 
31 is the initial channel 14. 

Then handover is performed by virtue of steps s34, s36, s38, s 10, s42, s44, 
1 5 s46, s48, s50, s52, s54 and s56 as will be described below. In this emb :>diment the 
implementation of these steps is conveniently considered as being d vided over 
the course of a second time period 32, a third time period 33, and a 1 purth time 
period 34, as shown in FIG. 3 and as will be described in more detai below. 



20 Referring to FIG. 3, at step s34, the message exchange during handover is 

initiated by the MN 6 sending a Reassociate-Request message from ts proposed 
new channel 15 to the new AP 5. The Reassociate-Request message |arries the 
Basic Service Set Identifier (BSSID) of the initial AP 4. 



WO 2005/060165 



PCT/EP2004/051740 



18 



This step s34 is implemented over the course of the second tiiAe period 32. 
The active channel of the MN 6 during this second time period 32 is the new 
channel 15. Thus, during the second time period 32 the flow of contAt data is, 
strictly speaking, interrupted (i.e. step s30 does not take place during the second 
time period), since the MN 6 has switched to its new channel 15, whjlch 
corresponds to the new AP 5 rather than the initial AP 4. 

However, this will usually only be for a very small time comj ared to the 
prior art process, because after implementing step s34 by sending th 
10 Reassociate-Request on the proposed new channel 15, the MN 6 rev#rts to the 
initial channel 14 to resume transmission and reception of content data on the 
initial channel 14. 

The resumed transmission and reception (flow) of content da ja on the 
1 5 initial channel 14 takes place over the course of a third time period 2 J. This takes 
place on an ongoing basis throughout the third time period 33, but f [>r clarity is 
schematically represented in FIG. 3 by means of a step s35 shown at the start of 
the third time period 33 and a step s51 shown shortly before the enc jof the third 
time period 33. In both step s35 and step s51, content data is passed between the 
20 MN6 operating on the initial channel 14, the initial AP 4, the IP netv ork 2 and 
the data route 8. In more detail, step s35 comprises: a step s35a in w rich content 
data is passed between the MN 6 operating on its initial channel 14 tnd the initial 
AP 4; a step s35b in which content data is passed between the initial AP 4 and the 
IP network 2; and a step s35c in which content data is passed betwe n the IP 
25 network 2 and the data route 8. Likewise, step s51 comprises: a step s51a in 
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which content data is passed between the MN 6 operating on its initi *1 channel 
14 and the initial AP 4; a step s51b in which content data is passed be tween the 
initial AP 4 and the IP network 2; and a step s51c in which content dilta is passed 
between the IP network 2 and the data route 8. The active channel of Khe MN 6 
during the third time period 33 is the initial channel 14, 

Whilst the above described data content represented by steps 535 and s51 
takes place, the new AP 5, the initial AP 4, the IP network 2 and the 
authentication unit 5 carry out handover steps as will now be descril ^ed. 

In this embodiment the mapping is again held at the authenti cation unit. 
Therefore, at step s36, the new AP 5 sends an Access-Request message to the 
authentication unit 3, this message including the information of the 1 >SSID of the 
initial AP 4. 

The authentication unit 3 processes this request, including loc king up the 
IP address of the initial AP 4 that it has mapped for the BSSID of the initial AP 4. 
At step s38, the authentication unit sends an Access-Accept message to the new 
AP 5. The Access- Accept message includes the IP address of the initi al AP 4. 

In this embodiment the option for the communication between the AP's to 
be encrypted or otherwise made secure is again employed. Hence, tl e Access- 
Accept message sent, at step s38, from the authentication unit to the new AP 5 
also includes a Security Key to enable the new AP 5 to prepare a sec irity block 
for sending to the initial AP 4. 
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Then security blocks are exchanged between the new AP 5 an i the initial 
AP 4. This is implemented as follows. At step s40, the new AP 5 senc s a Security 
Block to the initial AP 4. At step s42, the initial AP 4 sends a Security Block 
5 Acknowledgment to the new AP 5. (Note, in other embodiments wh ?re 
encryption is not employed, steps s40 and s42 may be omitted.) 

At step s44, the new AP 5 sends a Move-notify message to the initial AP 4. 
This Move-notify message in effect informs the initial AP 4 that the MN 6 has 
10 requested to handover to the new AP 5. 

At step s46, the initial AP 4 sends a Move-response message t d the new 
AP 5. This Move-response message and the Move-notify message ea ch include a 
Context Block. Both the Move-notify message sent at step s44 and th 2 Move- 

1 5 response message sent at step s46 are IP packets carried in a TCP ses sion 

between the two APs. These messages may contain authentication ii [formation 
that allows the new AP 5 to accept the MN 6 without re-authenticati Dn. 
However, the Context Block has a flexible structure which is able to support a 
range of information exchange. More specifically, it can consist of a variable 

20 number of Information Elements (IEs) of the form (Element ID, Lenj ;th, 

Information). In this way, every IE can contain variable length infor: nation, 
whose type is specified by the Element ID. Processing of the inform; ition 
transferred inside the IEs is beyond the scope of the IAPP, as it dep€ nds on the 
functionality of the APs, and will be arranged according to the requ rements or 

25 circumstances of a particular system or set up, as specified by the sk Llled person. 
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The Move-Response message sent at step s46 is based on and ndudes the 
contents of this message that are present under conventional IAPP si ^nailing. By 
virtue of this, the new AP 5 receives context information pertaining t ) the MN 6, 
which may include for example security context and Quality of Servi :e (QoS) 
context. Such QoS context may include both IP layer-2 QoS attributef , which are 
applicable to the WLAN radio interface, and IP layer-3 QoS attribute >, which 
specify end-to-end QoS requirements. Preferably a suitable layer-2 Q oS 
management scheme is employed, to provide for different kinds of t affic to 
10 receive acceptable service in the wireless link. 

Additionally, in this embodiment, for the sake of IP layer-3 Q< >S 
management, the Move-Response message sent at step s46 further includes an 
RSVP context. This RSVP context contains information about at least some, but 
15 preferably all, of the active IP flows, i.e. the data content and signal data flows 
being transmitted and received as part of the session. The new AP 5 might 
already have more current data flow than the initial AP 4, or at least relatively so 
compared to its capacity, due for example to other sessions of other MN's. 
Generally, for whatever reason, the new AP 5 may not be able to pro Ade as 
20 much bandwidth as the initial AP 4. These situations could mean the new AP 5 
would not be able to fully support the session currently previously h mdled 
satisfactorily be the initial AP 4, i.e. it might be that some of the IP dcjta flows of 
the session might not be supported if handover is implemented. 
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The new AP 5 performs an admission control algorithm to de ermine 
which flows can be accepted, based on the RSVP information receive i in the 
Move-Response message. At step s48, the new AP 5 sends a Move- A :cept 
message to the initial AP 4. The Move- Accept message includes the i nsults of the 
5 admission control algorithm. At step s50, the initial AP 4 sends a Ch nge- 

Command message to the MN 6 on its initial channel 14. The Chang< -Command 
message also includes the results of the admission control algorithm 

Depending on the admission control algorithm, the results ca i be either in 
10 the form of a simple set of flows that are accepted, implying that the|r will receive 
the same QoS level as in the old AP, or may as another possibility all o contain a 
new set of (reduced) QoS parameters per flow, in case the new AP 5 does not 
have enough resources to maintain the same level of QoS support. 

1 5 In this example the admission control algorithm results are a< ceptable to 

the MN 6. Hence, at step s52, the MN 6 sends an acceptance Change Response 
message to the initial AP 4 on its initial channel 14. The MN 6 then s vitches 
channels to its new channel 15, awaiting communication via the nev AP 5. In 
other words, the MN 6 has now completed its part of the handover ] process, and 

20 is now waiting for the new AP to start communicating with it. This < onstitutes 
the end of the third time period 33. In terms of the data content tram mission and 
reception as represented in FIG. 3 by steps s35 and s51, it will be apj reciated that 
step s51 represents the final data transfer on the initial channel 14. 
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(In the situation where the admission control algorithm result| are not 
acceptable to the MN 6, then the MN 6 does not send the acceptance Ihange- 
Response to the initial AP, and the handover process is terminated. ( >ne 
possibility is to specify that in this event the MN 6 should then try to handover to 
5 another AP instead of the AP 5.) 

At step s54, the initial AP 4 sends a Move-Command message to the new 
AP 5, which is in effect a confirmation to the new AP 5 that handove is going 
ahead. At step s56, in response to the Move-Command message, the new AP 5 
10 sends a Layer-2 (L2) Update Frame to the IP network 2. Steps s54 an< L s56 take 
place during a fourth time period 34 as shown in FIG. 3. This fourth ime period 
34 is characterised as a time period in which the MN 6 has once agaii t switched 
to its new channel 15 but is not yet in the process of passing data con tent on that 
channel. 

15 

In response to the Layer-2 (L2) Update Frame, the IP network 2 changes 
the data path to being switched via the new AP 5 instead of the initio I AP 4. This 
is represented in FIG. 3 by a step s58 in which the content data is pas >ed between 
the MN6 operating on the new channel 15, the new AP 5, the IP net™ ork 2 and 

20 the data route 8. In more detail, step s58 comprises: a step s58a in wt ich content 
data is passed between the MN 6 operating on its new channel 15 an i the new 
AP 5; a step s58b in which content data is passed between the new A P 5 and the 
IP network 2; and a step s58c in which content data is passed betwee i the IP 
network 2 and the data route 8. As before, although presented as a d screte step 

25 s58 for consistency in FIG. 3, it will again be understood that this rep resents an 
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ongoing two-way data flow process during a fifth time period 35, as hown in 
FIG. 3. This fifth time period 35 is characterised as a time period in \j hich the 
overall handover process has been completed and content data trans fer is taking 
place via the new AP 5 with the MN 6 operating on its new channel : 5. 

Broadly speaking, this embodiment tends to provide an advai tageous 
reduction in handover latency compared to the prior art method. Thi 5 is achieved 
by virtue of the MN 6 reverting to the initial AP 4 on the initial chaiu el 14 after 
having sent the Reassociate-Request message to the new AP 5 on the new 
channel 15 at step s34 during the second time period 32, thereby alio ving content 
data flow to take place during the third time period 33 while the nev^ AP 5, the 
initial AP 4 and the authentication unit 3 perform handover steps s3( -s50. 



This can further be appreciated by the following summary of fhe first to 
15 fifth time periods 31-35, as shown in FIG. 3, from the perspective of the MN 6. 

In the first time period 31, the MN 6 is communicating with tfHe initial AP 
4 on its initial channel 14, including the flow of content data. 



20 In the second time period 32, the MN 6 is switched to its new channel 15 

and is communicating a handover request, but not content data, to tile new AP 5. 



I! 
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In the third time period 33, the MN 6 is once again communis ting with 
the initial AP 4 on its initial channel 14, including the flow of content data. 



In the fourth time period 34, the MN 6 has once again switche i to the new 



10 



15 



20 



channel 15 and is awaiting further communication with the new AP 
content data flows in this fourth time period 34. 



>, i.e. no 



In the fifth time period 35, the MN 6 is communicating with tfe new AP 4 
on its new channel 15, including the flow of content data. 

Thus, it will be appreciated that content data flow takes place in the first 
time period 31, the third time period 33, and the fifth time period 35, but not in 
the second time period 32 and the fourth time period 34. This means there are 
two time periods when content data flow does not take place, whew as in the 
prior art method of FIG. 2 there is just one time period when conten data flow 
does not take place, namely second time period 22 of FIG. 2. Howev »r, the 
second time period 32 and the fourth time period 34 of the embodin ent of FIG. 3 
are singly and in total typically much shorter than the second time j eriod 22 of 
the prior art example of FIG. 2, thus typically providing an advantaj 
reduction in the total time that content data flow does not take plac 
the prior art approach. This tends to allow for transmission disruptil 
alleviated, which is particularly useful when the content data composes 
multimedia data. 
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The above described embodiment includes use of an RSVP coj Ltext and an 
admission control algorithm. However, these aspects are optional, ai d in other 
embodiments are not employed. In such an embodiment which is otherwise the 
same as the embodiment described above, this results in the f ollowir g 
differences compared to the above embodiment described with refer ince to FIG. 
3: 

(i) at step s46, there is no inclusion of an RSVP context in the Move- 
Response message; 

(ii) the new AP 5 does not perform an admission control algorithm; 

(iii) at step s48, there is therefore no inclusion of admission co itrol 
algorithm results in the Move-accept message; 

(iv) likewise, at step s50, there is therefore no inclusion of admission 
control algorithm results in the Change-Command message; 

(v) step s52, in which the MN 6 sends an acceptance Change-] Response 
message to the initial AP 4, will take place by default, or at least it w 11 not be 
dependent upon an admission control algorithm result. 



25 



In a further modified form of any of the above described embodiments, 
the need for content data flow to be interrupted during the fourth ti: ne period 34 
(i.e. while the Move-Command message and L2 Update Frame are s snt at steps 
s54 and s56 respectively) may be reduced or removed as follows. In the above 
described embodiment, the MN 6, having sent the acceptance Chan ;e-response 
message on its initial channel 14 at step s52, then switches channel t > the new 
channel and awaits completion of steps s54 and s56. In the modifiec version, the 
MN 6, having sent the acceptance Change-response message on its i nitial channel 
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14 at step s52, then remains on the initial channel 14 for a further am< unt of time 
so that content data flow may continue on the initial channel for som i or all of 
the time it takes the other system elements to complete steps s54 and s56. This 
further amount of time may be a predetermined amount of time, or i lay be 
5 determined according to an algorithm using knowledge of previous imes taken 
for steps s54 and s56 to be completed. Another possibility is that the *1N6 only 
remains on the initial channel 14 for the further amount of time if the signal 
quality is sufficient, i.e. above a predetermined threshold. 

10 In the above described embodiment, the example of handovei from AP 4 

is given, where the AP 4 is termed the initial AP 4 as the example is ( escribed of 
a scenario where access is initially provided via the AP 4. It will how iver be 
appreciated that the handover process described in the above emboc iment may 
also be applied, and forms part of the invention, when applied to an 

15 connection that is not necessarily the initial, i.e. first AP connection o : a particular 
data session. In other words, for example, the above described proce >s may 
equally be applied to a following handover from the new AP 5 to a f irther AP, 
not shown in FIG. 1, and so on. As such, it is to be understood that tl e 
terminology ''initial AP", and likewise the terminology "initial chani el", is used 

20 herein, including in the appended claims, for convenience to identifj the initial 
AP or channel so far as the current handover process is concerned, a id is not 
restricted to meaning the initial AP or channel so far as any other as\ ect, such as 
the current data session or call as a whole, is concerned. 
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In the above described embodiments, the invention is applied |o a WLAN 
operating according to an adapted version of the IEEE 802.11 standai d, and the 
handover process is a modified form of the Inter Access Point Protoc >1 (IAPP). 
However, in other embodiments the invention may be applied to WI ANs (or 
other access networks, see the following paragraph) operating accorc ing to any 
other suitable standards or protocols, including handover protocols, n this 
respect, it is noted that the invention is particularly advantageous wl en 
implemented in networks where so-called soft handover is not availc ble (such as 
the IEEE 802.11 standard WLAN in the above embodiment). NevertI eless, the 
invention is still applicable to and may still be employed advantageo usly in other 
types of access network even when soft handover is in fact available. In these 
situations, the present invention may for example be employed whei the soft 
handover process is either unavailable or of diminished performance , for 



whatever reason, or in any other form of combination or substitution 
handover. 



In the above described embodiments, the network in which 
is applied is a WLAN. In yet further embodiments, the invention is 
wireless wide area network (WW AN) instead of, or in addition to, a 
Generally, WLAN's and W WAN's may be considered as two types 
networks, and the invention may be applied to any access network. 



tie 



with soft 



invention 
abplied to a 
WLAN. 
access 
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In the above described embodiments, the WLAN comprises a i IP 
network. It will be appreciated that the IP network is just one examp e of types of 
transport networks (for example in an office block, or various office ocations of 
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an organisation, or e.g. throughout an airport, and so on) to which th s present 
invention may be applied. For example, in other embodiments the tr< nsport 
network may be a specific form of network, e.g. a communications n|twork 
operating according to IP, for example allowing voice over IP communication. 



